home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Diamond Collection / The Diamond Collection (Software Vault)(Digital Impact).ISO / cdr48 / 386p_200.zip / ASMPOWER.TXT < prev    next >
Text File  |  1995-01-13  |  8KB  |  176 lines
  1. ASSEMBLER POWER!
  2. Why you should consider 386Power for game devenlopement.
  3.  
  4. ------------------------------------------------------------------------------
  5. ------------------------------------------------------------------------------
  6. CHAPTER ONE:
  7. Some misleading objections to the use of assembly language
  8.  
  9. ------------------------------------------------------------------------------
  10. 1) C/C++ is as fast as assembly and it is easier to code
  11.  
  12. Right! C is NEARLY as fast as assembly if you use C as an "improved assembly"
  13. (read: if you heavily use pointer tricks and you code thinking carefully
  14.        at what the compiler will do with your code)
  15.  
  16. BUT ... if you have a "critical" loop that gets executed 90% of the time
  17. your program runs, the little speed difference between C and assembly
  18. becomes a 5..10 frames per second difference.
  19.  
  20. C is not easier to code than assembly, it is easier to learn and easier
  21. to port to another operating system (BUT ONLY IF YOU START CODING
  22. WITH BOTH EYES LOOKING AT EASY PORTING)
  23. ... that is, only if you code with an eye to the future.
  24.  
  25. Is not the language that makes a good program!
  26. I started programming in Pascal on an old Data General mini at the I.T.I.S.
  27. (sort of italian high school oriented to industrial applications)
  28. then i learned Z80 assembly, 68000 assembly, C
  29. then 8086 assembly, a little of Lisp and Prolog (very little)
  30. and at last 386 assembly.
  31. I see assembly as a "spartan" high level language and apply to it
  32. the same techniques (with an eye to code optimization).
  33.  
  34. I never had problems.
  35. I just thinked a lot and planned a lot what to do before start coding.
  36.  
  37. I never really needed a debugger, my brain was enough
  38. to simulate the program run and seek&destroy bugs.
  39.  
  40. The key for this ,is coding in modular way and if something fails
  41. restart from a previous "all system go" situation and start activating
  42. new code a piece at a time.
  43.  
  44. Antique aproach you say?
  45. Heck! This works for rocket scientists, it works for programming too!
  46. It is the method, not the tool what really counts.
  47.  
  48. Now comes the interesting thing, if you code in assembly you will know
  49. what is the exact code your cpu executes, excluding chip bugs
  50. and assembler bugs you know exactly what happens.
  51. If you use C ,the actual code (and compiler quirks) changes if you just
  52. switch a compiler option, the same can happen with an assembler but
  53. it is less frequent.
  54.  
  55. Yeah!
  56. There are some terror stories about bugs that only a debugger can discover ...
  57. But usually these bugs are produced by badly designed code.
  58. Planning and analisis takes 50% of code production, coding takes
  59. another 10% and profiling takes the other 40%
  60. if you coded correctly, debugging&testing will take another 100%
  61. ( expect spend twice the time you planned)
  62. BUT IF YOU CODED THE WRONG WAY d&t will take 10000% and you will be dead
  63. and this does not depend on the language you coded.
  64.  
  65. ------------------------------------------------------------------------------
  66. 2) C is portable and assembly is not.
  67.  
  68. Sort of... if you "mark" self modifying code and self-compiling code
  69. (so you will be able to quickly locate it for update)
  70. assembly becomes as portable as an high level language
  71. (you just need a code translator, and this is an easy thing to do)
  72.  
  73. IF YOU USE 386 ASSEMBLY you will never have to worry about porting.
  74.  
  75. 386 assembly is sort of "industry standard", supported by real cpus
  76. (from Intel,Amd,Cyrix,Nexgen,IBM ... even from the PowerPC 615 CPUs!!!)
  77. or by processor emulators running on powerful risc machines.
  78. What's more I CAN produce a cross assembler to port 386 assembly code
  79. to another instruction set (Heck! Last year i made a C to C++ translator
  80. assembly translation is a lot easier) (you just need to "translate"
  81. a finite state machine), if everything goes RISC i can produce
  82. a translator.
  83.  
  84. IS THE ENVIRONMENT WHAT MATTERS, that's why i introduced the XGE device drivers.
  85. With the correct drivers a 386powered program can run even on
  86. and X-window workstation.
  87.  
  88. ------------------------------------------------------------------------------
  89. 3) You need an high level language to write big programs.
  90.  
  91.    Don't think in term of "writing a big program", a game is mostly made of
  92.    images,sounds and FINITE STATE MACHINES describing "game agents"
  93.    and "game objects".
  94.    The actual program code is very little.
  95.    Instead of making lots of subroutines, make "generic" finite state
  96.    machines emulators, and then add the state evolution and output tables
  97.    needed to describe the various things.
  98.    As weird as it seems finite state machines looks all the same
  99.    so a f.s.m "engine" can be quickly coded in assembly.
  100.    With 386P+XGE you already have the foundation code, add some drivers
  101.    for your video/sound card and what's missing is just the specific code
  102.    to implement the finite state machines and some special effects.
  103.  
  104.    N.B. Don't ask me about "the other code needed to make a game engine"
  105.         the rest is very specific, it depends on what you want to do
  106.         and how you want to implement it
  107.         ( not to mention it is what makes the difference between
  108.           a fair game and a terrific-ultra-cool game).
  109.  
  110. ------------------------------------------------------------------------------
  111. ------------------------------------------------------------------------------
  112. CHAPTER TWO:
  113. How to correctly use assembly
  114.  
  115. 1) Plan a lot
  116.    The more time you spend planning what to do and how to do it
  117.    the less you will spend debugging,profiling and testing.
  118.    Also plan HOW to test is everything goes right and HOW to test
  119.    if something goes wrong, this speeds up debugging a lot.
  120.    This applies to every real world activity, but on things like programming
  121.    this is the key to get the job done.
  122.  
  123. 2) Use "deep thinking" optimizations only where you need maximum speed
  124.    in all the other parts use compact and easy to read code.
  125.    Stick lots of comments where the code gets tricky.
  126.    When you will reach the "all time optimizing mentality" you will easily
  127.    optimize the code as you type it and optimized code will look
  128.    easy to read (to you), but this takes some time, don't run too fast.
  129.  
  130. 3) Don't made lots of similar routines, made one that's generic enough
  131.    and if you wan to keep parameter passing simple, make multiple
  132.    "interface" routines (to reduce the code needed to stuff parameters
  133.    into registers or stack).
  134.    Use "different" routines only whe absolutely needed.
  135.  
  136. 4) Use assembly to MAKE bricks, NOT as a brick.
  137.    Then use the bricks to build the program.
  138.    Make things modular, but plan ahead how to subdivide things.
  139.    One of the reasons i delayed the distribution of 386P 2.00
  140.    was that i had not a clear vision about how to make the sound system modular.
  141.    (Gee! I hope i got it right!)
  142.  
  143. 5) Try to keep "clean" your code, use nasty tricks only where absolutely
  144.    necessary.
  145.  
  146. 6) Know when it's time to break the rules and when it's not
  147.    (only experience will tell you how).
  148.  
  149. ------------------------------------------------------------------------------
  150. ------------------------------------------------------------------------------
  151. CHAPTER THREE:
  152. The dos-extender advantage
  153.  
  154. The big advantage of using a dos-extender is that you program can run
  155. on anything from a plain ms-dos system to a RISC machine with a 386 emulator
  156. AND can always run faster than a plain 16bit ms-dos or Windows program.
  157. Some people think that the 32bit advantage is just more memory and
  158. 32bit access, wrong! There is also 32bit addressing!
  159. Accessing memory thru a single 4Gbyte segment you can almost forget
  160. of segment registers (almost!!!), you code quality improves a lot
  161. (no more fucking segments to swap around)
  162. AND the extra 32bit addressing modes can boost your program if you know
  163. how to use 'em.
  164. My 32bit code ROARS,it is TWO TO EIGHT TIMES FASTER than equivalent 16bit code.
  165.  
  166. Of course there are situation when the difference
  167. is nearly zero (accessing things byte-by-byte)
  168. or 16bit real-mode code is faster (when doing things that cause
  169. protection checkings), but you can limit 'em to the minimum.
  170.  
  171. If you deal with graphics and sound you will see and hear the 32bit difference!
  172.  
  173.  
  174.  
  175.  
  176.